home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19980901-19981211
/
000050_news@newsmaster….columbia.edu _Wed Sep 23 22:03:47 1998.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
5KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id WAA29989
for <kermit.misc@watsun.cc.columbia.edu>; Wed, 23 Sep 1998 22:02:23 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id WAA10364
for kermit.misc@watsun; Wed, 23 Sep 1998 22:02:23 -0400 (EDT)
Path: news.columbia.edu!sol.ctr.columbia.edu!news.mindlink.net!paralynx!paralynx-2!news.mindlink.net!paralynx!paralynx-3!paralynx!paralynx-4!van-bc!paralynx!paralynx-1!News.Vancouver.iSTAR.net!news.istar.net!nntprelay.mathworks.com!newsfeed1.earthlink.net!nntp.earthlink.net!posted-from-earthlink!not-for-mail
From: "Mr. Scott" <montgomery@starfleet.org>
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Can't get a transfer to work efficiently over a connection with a LanRover in-between.
Date: Wed, 23 Sep 1998 20:32:57 -0400
Organization: EarthLink Network, Inc.
Lines: 79
Message-ID: <6uc44u$hmn$1@oak.prod.itd.earthlink.net>
References: <6u43q3$fn2$1@ash.prod.itd.earthlink.net> <6u5mis$lnr$1@apakabar.cc.columbia.edu>
NNTP-Posting-Host: 1cust80.tnt1.atl2.da.uu.net
X-Newsreader: Microsoft Outlook Express 4.72.2106.4
X-Posted-Path-Was: not-for-mail
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
X-ELN-Date: Wed Sep 23 17:35:42 1998
Xref: news.columbia.edu comp.protocols.kermit.misc:9230
Allow me to rule out a few things.
1. It is not a transparency problem because the transfer works flawlessly
when packet-length is < 48 (and window size is 1).
2. It is not a flow control problem between our modem and UNIX because both
(as well as kermit itself) are configured properly: both are configured to
use RTS/CTS (and kermit); also transfers work at very high speeds with other
remote hosts with no problem.
Unfortunately there are no "settings" options at the LanRover prompt that I
can play with. They must be configured by the administrator using a
separate program.
This would all but point to some sort of problem on the remote end, wouldn't
you agree?
This is what we are asking the remote client to check:
1. Check that their modem is also using hardware flow control.
2. Check that their LanRover machine serial port is using hardware flow
control.
3. Check to see that the LanRover software is configured to work with
hardware flow contol.
Beyond this, the telnet part of the connection is through TCP/IP and needs
no flow control configuration, right?
Can you think of anything I forgot to ask them?
Frank da Cruz wrote in message <6u5mis$lnr$1@apakabar.cc.columbia.edu>...
>In article <6u43q3$fn2$1@ash.prod.itd.earthlink.net>,
>Mr. Scott <montgomery@starfleet.org> wrote:
>: Using kermit on AIX.
>: Dial into a LanRover, then use the lanrover's telnet command to get to
>: another Unix box.
>: When attempting to transfer a file from my local machine to the remote, I
>: get tons of timeout errors,
>: unless I bump the packet-length down to its minimum of 12 (with 4
windows).
>: It seems like there is a flow-control problem, but I have been
unsuccessful
>: in explaining/fixing this problem.
>: Does anybody have a suggestion?
>:
>Flow control is certainly a likely suspect. The LAN Rover port and the
>modem that is connected to it should be set to use some form of flow
control,
>and moreover the SAME form of flow control, and for maximum effectiveness
and
>transparency, this should be hardware (RTS/CTS) flow control. There is
>nothing you can do about the LAN Rover's modem, but there might be a
command
>available at the LAN Rover's prompt to let you check and perhaps alter its
>communication parameters.
>
>The same kind of flow-control problem might also be occuring between your
>local computer and its own modem.
>
>Second, some terminal servers are simply broken with respect to uploads.
>These are the ones that are disigned under the mistaken assumption that the
>vast preponderance of data flow will be TO the terminal, rather than FROM
it.
>
>I do not suspect a transparency problem at the LAN Rover, since if that
were
>the case, shortening your Kermit packets would make no difference at all.
>
>All of these issues are discussed at length in "Using C-Kermit". These
>discussions should help you home in on the problem and solve it.
>
>The current version of C-Kermit, by the way, is 6.0:
>
> http://www.columbia.edu/kermit/ck60.html
>
>- Frank